Service Point Triggers (SPT) are specified in the so called Initial Filter Criteria (IFC) of an IP Multimedia Subsystem (IMS) user which, in turn, belong to the service profile of a user subscribed to the IMS. The IFC is an XML-based IMS standard that may be used to define the order in which a session or a call or the like is routed across application servers. Such a routing may be conditional. This means that the session is routed to a specific application only when the session meets the criteria specified for that application. For example, it may be specified that the session is routed to a Virtual Private Network application server only when the session's Called Party Number begins with the asterisk (*).
A SPT comprises the conditions that the session or call must meet in order to, for example, the signaling of said session or call to be routed to a specific application server. Further, conditional statements using Boolean AND and OR conditions may be used between SPTs. For example, it may be specified that the session is routed to an application server, i.e. the application server is fired, if the following condition is met: (SPT1 OR SPT2) AND (SPT3 OR SPT4).
In short, there can be one or more SPTs with respect to a user. Conventionally, the SPTs contain conditions as to how an originating or terminating service or call, or even a registration, is to be dealt or handled. For example, a SPT may contain a condition as to how to further process, e.g. how to further route, a terminating Session Initiation Protocol (SIP) session addressed to the user, or a SIP call originated by the user.
If more than one group of SPTs exists for a user, they are evaluated according to a configured or pre-defined order of priorities. For example, a terminating SIP INVITE message may be first routed to a first Application Server AS1 according to a first trigger having the highest priority, and then to a second Application Server AS2 according to a second trigger having the second highest priority.
Internet Protocol (IP) Multimedia Systems (IMS) is a standardized technology which allows to perform, for example, Voice over IP calls (VoIP), by means of a core network layer and an application layer. The core network layer is composed of essentially three different functional entities (see 3GPP TS 23.228, chapter 4.6), a Proxy Call Session Control Function (P-CSCF), an Interrogating Call Session Control Function (I-CSCF), and a Serving Call Session Control Function (S-CSCF).
The Proxy Call Session Control Function (P-CSCF) is the point of entry to the IMS network from a user equipment (UE).
In other words, the P-CSCF is the first contact point within the IP multimedia core network (IM CN) subsystem. Its address is discovered by UEs using, for example, a mechanism as described in the section “Procedures related to Local CSCF Discovery” of 3GPP TS 23.228. The P-CSCF behaves like a Proxy, as defined in IETF RFC 3261 SIP: “Session Initiation Protocol” or subsequent versions, i.e. it accepts requests and services them internally or forwards them on. The P-CSCF shall not modify a Request URI in the SIP INVITE message. The P-CSCF may behave as a user agent as defined in the IETF RFC 3261 “Session Initiation Protocol”, i.e. in abnormal conditions it may terminate and independently generate Session Initiation Protocol (SIP) transactions.
The Interrogating Call Session Control Function (I-CSCF) is the point of entry from other operator networks.
In other words, the I-CSCF is the contact point within an operator's network for all connections destined to a user of that network operator, or a roaming user currently located within that network operator's service area.
Furthermore, the Serving Call Session Control Function (S-CSCF) is in charge of handling multimedia sessions and triggering the appropriate Application Servers (AS) to handle the services.
In other words, the S-CSCF performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services.
In turn, the application layer may be composed of one or several Application Servers (AS) which are in charge of executing the different supplementary services and other customized/proprietary operator services (e.g. virtual private network (VPN), pre-paid, or the like).
For example, an AS may be a Session Initiation Protocol (SIP) Application Server which may host and execute services. The SIP Application Server may further influence and impact the SIP session on behalf of the services.
Executing the different supplementary services may be achieved by interacting with the IP multimedia core network (IM CN) layer via the ISC interface between the S-CSCF and the AS, as described in 3GPP TS 23.218 (chapter 5.1.1). Furthermore, the AS may behave as SIP application servers on the ISC interface.
In 3GPP TS 23.218, cases are considered where the S-CSCF, upon receiving a user profile during an initial registration of the user in the IMS network, builds an ordered list of Initial Filter Criteria (IFC) to know which ASs are to be involved in handling an multimedia session and under which conditions, i.e. which services are to be checked/executed in association to the user when initiating or terminating requests. In addition, a configured order of priorities may be defined according to which the respective conditions are executed.
As further described in 3GPP TS 23.218 (section 5.2.3), the IFCs may be stored in the Home Subscribe Server (HSS) as part of the user profile and are downloaded to the S-CSCF upon user registration. They represent a provisioned subscription of a user to an application. In particular, the S-CSCF may request from the HSS the relevant set of IFCs that applies to the served (i.e., registered, unregistered, or both) user. On the other hand, if the S-CSCF has already a list of IFCs that is deemed valid, e.g., from a previous request, the S-CSCF may not request a new list of IFCs. In the case that multiple Filter Criteria are sent from the HSS to the S-CSCF, the S-CSCF may check the filter criteria one by one according to their indicated priority when the S-CSCF receives a message via the Mw or ISC interface.
The IFC may therefore contain information about a corresponding triggering that should be performed toward the different AS. Accordingly, an IFC may contain a group of SPTs which indicate conditions to be evaluated and an order to be followed when evaluating these conditions (priority of triggers). In other words, SPTs may be points in the SIP signaling on which Filter Criteria can be set. The IFC may also have a priority and an associated AS. In particular, this priority may be used to build an ordered list of IFCs, for example, to indicate in which order respective ASs are accessed or triggered.
If a condition (or set of conditions) is met, e.g. a SIP INVITE message originated from the user and containing a multimedia telephony indication (SPTs in this case are: (1) SIP method=INVITE, (2) direction of request=originating and (3) feature tag=Multimedia Telephony), then the IFC also indicates the AS to be involved in the IMS session, e.g. a Multimedia Telephony AS, as shown in Annex B.2.2 and B.2.3 in 3GPP TS 29.228 for example.
Therefore, current 3GPP scenarios with respect to IMS session handling indicate that conditions, i.e. the Service Point Triggers (SPTs), are evaluated based solely on the information received in the SIP request received, as described in 3GPP TS.23.218 (see figure and detailed steps in Annex C thereof).
For example, when two application servers AS1 and AS2 are assigned to provide additional services to a subscriber in a first step, a user initiates a SIP session by sending a SIP initial request to its S-CSCF.
Then, on receiving this SIP initial request, the S-CSCF evaluates the SPTs and checks if they match first initial filter criteria for a first application server (AS1). If they match, the S-CSCF forwards this request to AS1, i.e. triggers AS1.
Then, the AS1 performs any needed service logic based on the Service Key and sends the SIP request possibly with service related modification back to the S-CSCF.
On receiving the request from the AS, the S-CSCF evaluates the SPTs and checks if they match second initial filter criteria for AS2. If they match the S-CSCF forwards the request to the associated Application Server AS2, i.e. triggers AS2.
On the other hand, if the request doesn't match any further filter criteria, the S-CSCF forwards this request to the next hop based on the route decision.
The AS2 then performs any needed service logic based on the Service Key and sends the SIP request possibly with service related modification back to the S-CSCF.
If the S-CSCF checks the request sent by AS2 and finds that no initial criteria is matched, then the S-CSCF forwards this request to next hop based on the route decision.